这篇文章分享我对汽车行业的流程、质量、体系效率、工具的理解，以及如何在蔚来汽车和上汽零束的工作中，获得创业灵感，也尝试说明 MappingSpace 的诞生过程与设计理念。

初进蔚来 —— 为什么软件问题还没解决？

硕士毕业之后，我进入蔚来汽车做质量管理。当时我在工厂整装车间的最后一道环节：站在用户角度对车辆质量进行评审。18 年上半年，量产冲刺的最后阶段，我们几乎每周都会抽 1-2 辆车进行完整的用户角度评审。当时外观、内饰问题已逐渐收敛，但软件还存在较多问题。

我当时负责整车软件功能的评审。刚接触这块儿时非常兴奋，理论上来说，我是第一个 "用户"，完整摸到了当时中国第一辆真正量产的高端智能电动汽车。但一年的质检体验，给我泼了一盆冷水。临近量产，外观、内饰的问题越来越少，而软件的问题还没有彻底解决。

当时有一次机会，我在工厂给智能座舱的测试总监演示整车功能。他坐在 ES8 的后座，看我对整车功能甚至是一些还未开发出来的功能如数家珍之后，他非常好奇，为什么一个工厂质量端的同事，能够对整车软件功能如此清楚。在一个合适的机会下，我转到了智能座舱的测试部门。

智能座舱 —— 保交付还是保质量？

在智能座舱测试团队，我做的第一件事是规范测试团队的流程。当时的测试团队，没有成体系地记录完整的测试用例，许多功能测试都是基于测试工程师的个人能力，不同测试工程师测试结果差异非常大。

因此，我做的第一件事情，就是推动测试用例的书面化和结构化。当时碰到了很多阻力，测试同学最大的抱怨是：测试任务非常繁重，软件版本发布频率非常快，他们没有时间去写测试用例。

当测试用例开始编写后，我发现一个现象：测试工程师特别喜欢用思维导图来编写测试用例。 不仅他自己编写的时候思路清晰，对于评审的人来说也是如此，能够快速指出测试提纲里面缺少何种测试场景。相比于一个 Word 或者 Excel 文档，编写和评审的效率都大为提高。

但是，受限于测试用例仍然是线下的思维导图或者 Excel，需求、开发同学看到的测试提纲往往是滞后的。这就造成了需求和测试用例经常不一致。

测试提纲评审完之后，测试工程师开始执行测试。我原以为他们会直接看着思维导图来执行，但实际情况并不是这样 —— 他们会把思维导图拆解成一份 Excel，每一行就对应一条测试用例，一条条手动创建。这无疑是重复工作。

为什么不就在思维导图里，保存测试用例的全部信息呢？为什么不直接用思维导图，出具一份测试执行报告呢？ 这个问题的答案，就是 MappingSpace 最初的创意来源。

软件质量 ——ASPICE 是救命稻草？

蔚来在成立前几年，不计成本地投入来抢时间，来快速发布产品。快速扩张带来了一系列后遗症：研发流程体系还没稳定的情况下，正向研发一下子开辟了 N 条战线，研发工具山头林立，工具分散，各个部门内部的工具链尚且无法在短期之内打通。

在一次公司内部的培训中，我才了解到汽车行业有一个专有的软件质量流程标准 ASPICE。当我花了一两周的时间深入去了解这个标准后，发现这个标准里面提到的很多理念，都和我之前接受过的质量教育很相似，我仿佛看到了解决质量问题的曙光。

我去向 leader 建议，是否应该采用 ASPICE 的开发模式。但他当时也提出了一些疑问：团队成员基本都是手机行业或者互联网行业出身，对 ASPICE 都不太懂，如何从现在这样一种开发模式转到另外一种开发模式，这是一个比较大的问题。另外 ASPICE 对于文档的追溯性要求非常高，我们如何才能在现在这样一种保交付的氛围下，建立详细的过程文档？

后来，我尝试着在 Jira 这样一个敏捷开发系统中，去建立 ASPICE 所期望的详细文档和追溯性。不过由于对团队现有的流程改动非常大，这个方案甚至还没说出来，就不得不夭折了。

上汽零束 —— 工具试验场

在上汽零束成立不到半年的时候，我进入基础软件团队做软件质量管理工作。当时我已经慢慢开始了解 ASPICE 更加具体的做法，一心以为 ASPICE 就是解决汽车软件质量问题的关键。

当时碰到一个比较大的问题是，想实施 ASPICE，但工具难落地。我们沿用了上汽西门子的 Polarion 软件，但是 Polarion 软件出现了一系列问题：智能座舱团队已经启用了 Jira，因此 Polarion 和 Jira 之间需要做数据同步。不同部门又引入了 TAPD。3 个部门内部都在建立以各自的研发管理软件为中心的 CICD 流程。

为什么他们不愿意用同一套工具来做整个公司的研发管理？ 不是不想用一套工具，而是在市面上找不到这样的工具。Jira+Confluence 是敏捷开发的领袖级解决方案，但如果你想用它来做汽车行业的研发管理，想要满足 ASPICE，没有现成的装修方案。Polarion 能够支持 ASPICE，但软件界面的交互和功能易用性，都让人望而却步。

离职创业 —— 用工具辅助人类的思维方式

那我能不能做出这样一款工具：

她既能支持高效的敏捷开发，又能在不增加工作量的情况下，满足 ASPICE？

她必须能同时支持需求管理、开发管理、测试管理，而不是在不同的工具间反复横跳。

她不应该有太高的学习成本，她的核心逻辑只需要 5 分钟就能掌握。

"思维导图是一种可以激发创造力和促进创新的工具。"

如果思维导图能够解决多维度的数据存储问题，那么它不仅能支持条目化，还能真正用于编写一篇复杂且详细的工程技术文档。因此我们创造性地给思维导图增加了浮窗，并且支持各种类型的数据存储。

产品工程师用思维导图来编写需求文档，思路像流水一样清晰；架构工程师用思维导图来编写架构设计文档，所有人都能清晰看懂他的思路；测试工程师用思维导图来编写测试用例，再也不用担心别人看不懂他的测试设计思路。

MappingSpace 高效地解决了大部分研发中的事情：需求、架构梳理的时间节省了 50%，评审时间节省了 40%，测试活动的效率整体提高了 60%。